Piping Screen Share誕生経緯
画面共有する理由: 汎用性が高い
画面共有したい理由は、汎用性の高さ。
PC上で見ているすべてのものを転送できるため、見せたいものを見せやすい。
ターミナル共有よりも汎用性が高い。ターミナルを画面共有すればよい。
グラフィカルなものも転送できる。
画像でも動画でもプレゼン資料でも。
プレゼン発表のときに良くある映像出ない問題もセキュアかつ手軽に画面共有できれば、映像接続できているPCに画面共有してとりあえず乗り切る最終手段としても使える。
Piping Screen Shareの動画にフルスクリーン機能があるのは、これのためだったりする。
ffmpegコマンドによる画面共有の問題点
まずは良いところから。
ffmpegで画面キャプチャしつつ画面共有できる。
パイプ使えるので、Piping Serverとの相性も良い。そのパイプの間に暗号化処理を挟めばエンドーツーエンド暗号化可能。暗号化しなければブラウザでURLにアクセスだけで見る側がすぐに動画見れる。見る側の負担はすごく少ない。
ただし、3秒ぐらい遅延してしまう。タイムリーな使い方の場合は3秒は遅い。
暗号化するとコマンドにもよるが最も普及しているであろうopenssl使うともっと遅延する。
ffmpegのバッファ関連のオプションをいじったり、動画形式を変更したり、試したがまだ遅延を減らすことに成功できていない。
他の試み:macOSのAVFundation
ffmpegの遅延問題の発生場所は共有する側。見る側は問題ないはず。
macOS限定で画面を遅延なしに共有するためにSwiftでスクリーンをストリーミングできるCLIを作る試みを以下のリポジトリでしている。
画面録画はでているはず。ただし、その動画データを標準出力に吐き出す仕組みが見つけられず止まっているはず。
ファイルパスを指定してファイルに書き出すようなAPIになっていたはず。/dev/stdoutなどを指定してもうまく行かず。ファイルパスをしていしないAPIを探したりもしたはず。ffmpegもmacOSだと、AVFoundationを使ってちゃんと標準出力に動画データをストリーミングできている。それに該当しているであろうffmpegのソースを探して読んだりもした。
ただ、結果的にはまだ標準出力にストリーミングできる方法を見つけられてはない。
Piping Screen Share (Web版)
遅延は1/3の1秒ほど。個人的には許容範囲。500msごとで動画チャンクがきて、ダブルバッファするため遅延が1秒ぐらいになる。
どうやって遅延をはかっている?
コラム的なもの。
現在時刻を知れるのようなサイトを画面共有して、共有された画面を見つつ秒の部分がどれだけ差があるかを見ている。厳密に計測するには他の方法がいると思う。